Generally streaming media services entities are a client and a server, which represents the two endpoints involved in providing the media to a user of a user terminal, wherein the client is generally implemented in the user terminal. The media content, e.g. video, may be distributed on several servers on e.g. the Internet, and the client's requests are directed towards the most suitable server, e.g. the closest and/or the one that currently serves least amount of other clients.
More and more online video services are utilising video rate adaptation in order to provide a good user Quality of Experience, QoE, in varying network conditions. In the marketplace, several different versions of Hypertext Transfer Protocol, HTTP, adaptive streaming are implemented by different vendors such as HTTP Dynamic Streaming, HDS, developed by Adobe, HTTP Smooth Streaming, HSS, implemented by Microsoft, HTTP Live Streaming, HLS, provided by Apple. Dynamic adaptive streaming over HTTP, DASH, also named HTTP Adaptive Streaming, HAS, has been adopted by the 3rd Generation Partnership Project, 3GPP, targeting to unify behaviours for different vendors. The video server may be incorporated in normal web servers with storage of video representation with different codec rates.
In DASH (and most of the other versions), a video clip is composed of multiple representation layers with different resolutions. Each layer is encoded with Constant Bit Rate, CBR, or Variable Bit Rate, VBR, encoding algorithms. Such organisation gives finer scalability which can adapt to the client variants and different network bandwidths. At the start of a video session, the client fetches a Media Presentation Description, MPD, from the streaming server, or media server, for the requested video clip. The MPD conveys detailed characteristics of the requested video clip using a hierarchical data model, which for example includes the timing, segmentation duration, Uniform Resource Locator (URL), video bitrates, resolutions etc. Based on the information in the MPD the client initiates a video request with the initial rate (which is typically a low rate) to the video server. The video request is followed by a bundle of video frames transmitted by the streaming server, or media server. The bundle of video frames also called video segments is composed of consecutive frames in a time interval of several seconds. The client may select a new media rate, from the rates given by the MPD, based on the estimated available network throughput and/or the amount of video in a play-out buffer of the client.
Hence, the client consists of:                A user application interface, API, that interacts with the user and provides, videos to select from, and play-out control functions, such as play, rewind, fast forward, pause.        A display and speakers, on which the user looks and hears the media.        A play-out (playback) buffer, that contains the media to render (playback) to the user on the display.        A playback point function, which keeps track of where in the media file the playback is.        A media rendering functionality, which takes media from the play-out buffer and playback it to the user.        A media rate adaptation algorithm, commonly based on throughput/bandwidth estimates, or play-out buffer level that selects based on the MPD information which segment to fetch.        A media get (fetch) functionality from the server, commonly based on HTTP.        
Several problems may arise with the client-server solution described above. It may be hard to perform accurate DASH client-side bandwidth or throughput estimation above the HTTP layer. As a result, video rate adaptation may be based on inaccurate estimates which may lead to undesirably variable and low-quality video. In order to overcome this problem, buffer-based rate adaptation algorithm may be used that does the rate selection based on the current buffer level. However, although the buffer-based rate adaptation reduces the buffer underrun and may increase the media rate through the session it suffers from increased rate changes that may negatively affect the QoE, furthermore, buffer based adaptation typically require large play-out buffers in order to get a reasonably stable rate control loop. To reduce the amount of rate changes it may be possible to look ahead on the sizes of potential coming segments, and also consider that in the rate selection. Still, during peak hours the media rate achieved with the buffer based and look ahead scheme for media rate adaptation is lower than the common bandwidth or throughput estimate based rate adaptation. This is due to that the client lacks full knowledge of the system load as the client cannot conceive what happens with other clients sharing the same resources.